Data networks, such as frame relay and asynchronous transfer mode (“ATM”) networks support the high speed transfer of video, audio and computer data in packets over a circuit established between a host device and one or more remote devices. The circuits in a data network comprise multiple logical connections called permanent virtual circuits (“PVCs”) which must be provisioned in the network. In a typical data network, PVCs are provisioned upon receiving a service order designating various transmission characteristics for data in a network management system (“NMS”). The NMS may comprise a computer system running specialized software configured to recognize and process service orders received in the NMS. A typical service order (“SO”) contains service type information which identifies a network service provided to customers. For example, service type information in a service order may describe a frame relay service.
Generally, an NMS may only process service orders for a limited number of supported service types. Currently, these service types are recognized by looking for a particular identification or “signature” within received service order data and comparing it to a known identifier coded in the NMS software. Once a service type is recognized in the NMS, the service order is processed based on algorithm supported for the service type.
Recent advances in communications technology have resulted in the creation of new service types which are required to be recognized and handled by the NMS in a hybrid data network. For instance, an NMS in a hybrid frame relay network may receive service orders including service types for metro Ethernet service, multicast Frame Relay service, or a customer managed network service, among others. Currently, the addition of these service types requires an update of the NMS software code so that they may be identified. However, current methods for updating the NMS software code to recognize new service types suffer from several drawbacks. One drawback is that the deployment of updated software code requires a shutdown and restart of the NMS computer system, resulting in undesirable downtime. Another drawback is that prior to deployment, additional time must be allocated to develop and test the updated software for recognizing and processing the new service types.
It is with respect to these considerations and others that the present invention has been made.